cc @wenjiaswe @jingyih

@serathius @ptabor This is pretty big change. What's the context? Also, we need to document this in the CHANGELOG.

@gyuho is renaming package considered a big change (not counting a number of lines changed)? It just an git mv and sed to rename imports.

As for CHANGELOG, what kind of changes we document there? I would expect that changelog should include user facing changes, is renaming package within server package a user facing change? I would expect it true for api package, but not for server. Please let me know if I'm missing something.

Context: We are introducing a versioning of storage as proposed in #13168. To properly version fields stored in bbolt we need to abstract logic that marshals field values into bytes stored in bbolt. This PR moves mvcc package as subpackage of new storage package to create place for higher level abstraction that will be aware of storage version.

Even without storage version effort I think that moving all file manipulation under single package is an improvement to package structure.

SGTM. Thank you.
Reviewed and the change is a refactor without any BL changes.

I find the new structure cleaner:

• /storage/backend (abstraction of bbolt)
• /storage/mvcc (revisions storage)
• /storage/schema (remaining metadata (versions, members, leases) stored in bbolt)

Than the current mvcc that mixes both roles.

I also like making the enormous (2700loc): server/etcdserver/server.go smaller

Deferring the decision to @gyuho

@serathius

As for CHANGELOG, what kind of changes we document there? I would expect that changelog should include user facing changes, is renaming package within server package a user facing change?

Please update CHANGELOG. We should try to document any changes made to the public packages (unless we move this to internal) -- the package mvcc is used for benchmark tools.

LGTM thanks.

PTAL @gyuho @ptabor

lgtm thanks @serathius !